home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9707 / 000021_neil@causality.com _Thu Jul 3 10:13:26 1997.msg < prev    next >
Internet Message Format  |  1997-11-30  |  3KB

  1. Return-Path: <neil@causality.com>
  2. Received: from fm3.facility.pipex.com (fm3.facility.pipex.com [194.131.104.13]) by odie.barnet.ac.uk (8.8.2/8.8.0) with SMTP id KAA23437 for <willy@odie.barnet.ac.uk>; Thu, 3 Jul 1997 10:13:26 +0100
  3. Received: from succexpr.demon.co.uk [158.152.208.192] 
  4.     by fm3.facility.pipex.com with smtp (Exim 1.59 #22)
  5.     id 0wjh3U-0000FD-00; Thu, 3 Jul 1997 09:15:56 +0100
  6. Date: Thu, 03 Jul 1997 10:03:57 +0100 (BST)
  7. From: "Neil A. Carson" <neil@causality.com>
  8. Subject: Re: Re ELF
  9. To: Matthew Wilcox <willy@odie.barnet.ac.uk>
  10. Cc: linux-arm@vger.rutgers.edu
  11. In-Reply-To: <199707030812.JAA22989@odie.barnet.ac.uk>
  12. Message-ID: <Marcel-1.09-0703090357-b49f3nA@succexpr.demon.co.uk>
  13. MIME-Version: 1.0
  14. Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
  15. X-Organization: Causality Limited
  16. X-Mailer: ANT RISCOS Marcel [ver 1.09]
  17. Status: RO
  18.  
  19. On Thu 03 Jul, Matthew Wilcox wrote:
  20. > > No, only if you're silly. If you're clever, you only do 16Kb.
  21. > I misremembered DECs recommendation then.  Sorry.
  22.  
  23. This is the noddy way of doing things. For example Digital's own code in their
  24. NC only uses 16kb :-) Maybe they've forgotten!!
  25.  
  26. > > I diasgree. Not many CPUs need to do this and considerably worse, I can't
  27. > > think of any mainstream ones to hand...
  28. > Other CPUs have to /effectively/ do this (ie flush the caches on a context
  29. > switch).  It's just that on the ARM, you have to do this yourself.  I was
  30. > basing the 'considerably worse' on the fact that other CPUs have large L1
  31. > caches.
  32.  
  33. No, they don't. Other processors cache by physical address, not by virtual
  34. address. So when memory is remapped they do not need to reflush. Some can
  35. also have memory-coherent caches, so even if you DMA in you still don't
  36. need to do a cache flush even if multiple CPUs are present (see the BeBox
  37. for example). The ARM caches by virtual address; this allows the MMU to run
  38. slower (and thus use less power) and also removes some extra logic.
  39.  
  40. > Cos 64MB * 48 = 3GB.  I was assuming the top GB would be reserved for
  41.  
  42. But so what? Why should you have to have a fixed size for every process?
  43.  
  44. > various bits of iffiness like kernel workspace and mapping devices into
  45. > and so on.  I suppose you could always do the Minix Thang and get each
  46. > binary to declare how much space it required and get more tasks in that
  47. > way, but then you end up with fragmented address spaces and all sorts of
  48. > horrible things.  Or you could maybe trade off a little - 96 tasks each
  49.  
  50. No. I agree with you it's nice a nice idea - but why would you have to do
  51. this? Allocate 1meg for each descending stack. You now how big a processes
  52. text area is so you only allocate it that for code. Data are is initially
  53. of a known size, and you could redirect calls to memory allocation to use
  54. somewhere else in the memory map.
  55.  
  56.     Neil
  57.  
  58. -- 
  59. Neil A. Carson
  60. Marketing Director              Causality Limited (London, UK)
  61. Tel/Fax: +44 (0)181 930 7408    Mobile: +44 (0)370 593183
  62. Email: neil@causality.com       WWW: http://www.causality.com.